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ABSTRACT 

This paper presents the development of a virtual spacecraft simula¬ 
tor game, where the goal for the player is to navigate their way to 
various planetary or stellar objects in the sky with a sonified poi. 
The project utilises various open source hardware and software plat¬ 
forms including Stellarium, Raspberry Pi, HappyBrackets and the 
Azul Zulu Java Virtual Machine. The resulting research could be 
used as a springboard for developing an interactive science game 
to facilitate the understanding of the cosmos for children. We will 
describe the challenges related to hardware, software and network 
integration and the strategies we employed to overcome them. 

1. INTRODUCTION 

HappyBrackets is an open source Java based programming environ¬ 
ment for creative coding of multimedia systems using Internet of 
Things (IoT) technologies [T). Although HappyBrackets has focused 
primarily on audio digital signal processing—including synthesis, 
sampling, granular sample playback, and a suite of basic effects-we 
created a virtual spacecraft game that added the functionality of con¬ 
trolling a planetarium display through the use of WiFi enabled Rasp¬ 
berry Pis. The player manoeuvres the spacecraft by manipulatin g a 
sonic poQ which is usually played in the manner shown in Figurejl] 
The poi contains an inertial measurement unit (IMU), consisting of 
an accelerometer and gyroscope; and a single button. The goal of the 



Figure 1: The conventional way of playing a sonic poi. 


game is for a player to choose an astronomical object, for example a 
planet or star, and to fly towards that object. This enables the player 
to view other objects, including planets, moons, stars and galaxies in 

1 "Poi spinning is a performance art, related to juggling, where weights on 
the ends of short chains are swung to make interesting patterns. "(Up. 173] 


the field of view. For example, Figure [2[shows how the player might 
view Saturn from Earth, while Figure [5] shows how the player may 
view Saturn from their spacecraft. The sonic poi generates sound 
that is indicative of the player’s field of view. Additionally, the poi 
provides audible feedback when the player zooms in or out. 


Figure 2: Saturn viewed from the ground from Stellarium. 



Figure 3: A closer view of Saturn from Stellarium. 


The University of New South Wales required a display for their 
open day to showcase some of the work conducted in the Interactive 
Media Lab. The opportunity to develop an environment whereby vis¬ 
itors could engage with the technology we were developing would 
not only facilitate attracting possible future students, it was also a 
way to develop and test the integration of various research compo¬ 
nents we were conducting. Many managers and business seek to en¬ 
gage new customers through gamification 0—in this case, prospec¬ 
tive customers were potential students. Furthermore, research indi¬ 
cates that visualisation and interpretation of software behaviour de- 
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veloped as part of a game is more memorable, which facilitates locat¬ 
ing errors or developing methods for improvement n Developing 
a game, therefore, would not only engage the visitors, it would pro¬ 
vide us with a more memorable way of seeing how our system was 
behaving. 

The technology to develop the game required two different ver¬ 
sions of Raspberry Pi, installation of planetarium software onto one 
of the Pis, and the creation of a Java API to join the different sys¬ 
tems. This paper details the strategies and techniques to integrate the 
different technologies and describes some of the workarounds for 
unresolved issues. We also discuss the goals, rules and rewards used 
to define the game and the methods we used to entice prospective 
players. Finally, we lists areas where the research can be extended. 

2. BACKGROUND TO RESEARCH 

The research was inspired by a previous project developed by one of 
the authors that correlated what a viewer saw in the night sky through 
binoculars with data obtained from on-line astronomical data cata¬ 
logues (5). One installation, which was conducted in conjunction 
with the Newcastle Astronomical Society on one of their field view¬ 
ing nights, was particularly successful m. More than twenty mem¬ 
bers of the public were enticed into viewing the night sky through 
high powered binoculars while sound that was based on data from 
the stars they were viewing was playing through loudspeakers on the 
field. 

Another set of performances was conducted with an improvis¬ 
ing ensemble that featured various astronomical photos displayed as 
a slide show to The stellar data was mapped as MIDI and success¬ 
fully functioned as inspirational impetus for the performers, but was 
unsuccessful from an astronomical point of view. First, the ability 
for viewers to look through the equipment was directly dependant 
upon the weather. One performance, for example, had a night sky 
complete with thick black cloud, heavy rain and lightning. More¬ 
over, when the weather was favourable for viewing, the audience 
were often content to just watch the performers rather than venture 
out of their chairs to view through the binoculars 0. The audience 
feedback from the was that although they really liked the slide show, 
many were unaware that the binoculars were even there for view¬ 
ing. Instead of providing a slide show at the next performance, an 
improvisation using Stellarium from a laptop computer was used on 
the screen. The audience’s response was extremely favourable, in¬ 
spiring the idea of using Stellarium as a visual stimulus instead of 
binoculars. 

2.1. Raspberry Pi 

The Raspberry Pi was originally developed in 2011 0 for educa¬ 
tion by the Raspberry Pi Foundation, a UK based educational charity 
19l ifTOl . The Raspberry PI has a very large user base and a signifi¬ 
cant number of plug in sensors available for it ED, and supports a 
128GB SD card, which can be used to store more than 200 hours of 
high-quality audio. The Raspberry Pi foundation officially supports a 
derivative of the Linux distribution Debian known as Raspbian Q2- 
Raspbian’s inclusion of compilers, support for multiple coding lan¬ 
guages, and the ability to run multiple programs provides the flexi¬ 
bility that enables a system to expand as an interactive platform as 
newer technologies become available. The game project used two 
different versions of Raspberry Pi and Raspbian. The sonic poi re¬ 
quired a small form factor, low power consumption but did not re¬ 
quire a GUI, and consequently, Pi Zero running Raspbian Stretch 


Lite was selected. The device used to display the graphics required 
significantly more power but did not have size restrictions, so a Rasp¬ 
berry Pi B+ running the desktop version of Stretch was selected for 
this. 


2.2. HappyBrackets 

HappyBrackets commenced as "A Java-Based remote live coding 
system for controlling multiple Raspberry Pi units" E3 where a 
master controller computer sent pre-compiled Java classes to selected 
Raspberry Pi devices on a network. Unlike the Arduino sketch, 
which is effectively a single program fl4l . the HappyBrackets com¬ 
position is not a standalone executable program. The HappyBrackets 
core has a thread that listens for incoming bytecode classes, and after 
receiving the class, executes the new class’s functionality through a 
Java interface. This allows for multiple concurrent compositions that 
can be easily created or updated during composition or the creative 
coding performance m. This research was extended with the de¬ 
velopment of the Distributed Interactive Audio Device (DIAD) CD, 
which contained an IMU consisting of an accelerometer, gyroscope 
and compass. The devices were handled by the audience and incor¬ 
porated into the environment. The DIADS not only responded to 
user manipulation, they also responded to one another. Furthermore, 
DIADS were configured to automatically connect to the wireless net¬ 
work, and once a DIAD came into range of the network, became a 
part of the DIAD multiplicity. The main focus of this development 
was the implementation of a reusable platform that allowed creators 
to easily develop interactive audio and easily deploy it to other de¬ 
vices. Although HappyBrackets runs on many embedded platforms, 
the main research has been with the Raspberry Pi, primarily due to 
the availability and low cost of the devices. HappyBrackets is li¬ 
censed under the Apache License 2.Cnand is available through Git 

HutEI 

A prebuilt disk image—which contains the Java Virtual Machine 
(JVM), the I2C drivers to enable access to the IMU, and libraries to 
access the GPIO—enables users to flash an SD card and start us¬ 
ing HappyBrackets without ever having to connect their device to 
the Internet. The licence for the Oracle JVM, however, appeared to 
prohibit embedding the Oracle JVM into a prebuilt image and was 
therefore legally problematic. We found that the AZUL Zulu JVM 
was available under the GNU GPLv2 licenc^] enabling an embed¬ 
ded distribution within an image. Medromi et al. conducted a study 
that compared the two JVMs GE Their tests revealed that Zulu 
created more threads and classes than Oracle, indicating that Zulu 
probably used more memory, making it more susceptible to garbage 
collection issues. Furthermore, their tests showed that Zulu also used 
a greater percentage of CPU, indicating greater power consumption. 
The report, however, did not detail the difference in performance 
speed between the two JVMs. Our own initial tests did not show 
any difference between the two JVMs and there was no noticeable 
performance degradation, however, this is an area we still need to 
research. It is possible to change the default JVM used in the Rasp¬ 
berry Pi from the terminal, which would make switching between 
JVMs when performing comparative tests relatively easy. 


2 www.apache.org/licenses/ [accessed November 2018] 

3 github.com/orsib/HappyBrackets [accessed November 2018] 

4 www.gnu.org/licenses/old-licenses/gpl-2.0.txt [accessed November 
2018] 
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2.3. Stellarium 

The advancement of computing power over the last two decades 
has made the availability of planetarium software available on both 
desktop computers and mobile devices commonplace. Moreover, 
many of these software packages—including RedShif^ SkySafar^j 
StarMai Q The and Stellariun^— have become valuable tools 

for astronomers. They facilitate the identification of objects and in 
the planning of viewing and astro-photography sessions by enabling 
sky simulation for any particular location, date and time ED 

Stellarium is an open source software project distributed under 
the GNU General Public Licence with the source code available 
through Git Hulp], Stellarium functions as a virtual planetarium; 
calculating positions of the Sun, moon, stars and planets based on 
the time and location defined by the user. Moreover, the viewing 
location does not even need to be on Earth. For example, Figure [4] 
displays Stellarium rendering Jupiter viewed from its moon Io. 


Hi 


Figure 4: A simulation of Jupiter viewed from Io. 

Stellarium is used by both amateur and professional astronomers, 
and is used by the European Organisation for Astronomical Research 
in the Southern Hemisphere to facilitate distribution and sharing of 
visual data among scientists ED. Stellarium has a very high quality 
graphical display, supporting spherical mirror projection that can be 
used with a dome ED. Stellarium is used in many schools and mu¬ 
seums because it is both scientifically accurate and visually engaging 
ED- Moreover, it is suitable for demonstrating basic through to ad¬ 
vanced astronomy concepts GD. Stellarium has a built in library of 
600 000 stars, with the ability to add an additional 210 million ED. 
Moreover, Stellarium can display constellations from several differ¬ 
ent cultures and has labels translated to more than 40 languages, 
making Stellarium both culturally aware and inclusive ED. 

Although it is quite straightforward to control Stellarium using 
a keyboard and mouse, there are many plugins that allow third party 
integration with the software. The plugin we were particularly in¬ 
terested in to control Stellarium was the Remote Control, which en¬ 
abled control of Stellarium through HTTP ED . Stellarium also con¬ 
tains a powerful scripting engine that enables one to program and 
run complete astronomy shows. The scripts, written in JavaScript, 


5 www.redshift-live.com [accessed November 2018] 

6 www.southernstars.com [accessed November 2018] 

' www.star-map.fr [accessed November 2018] 

8 www.bisque.com [accessed November 2018] 

9 stellarium.org [accessed November 2018] 

10 github.com/Stellarium/stellarium [accessed November 2018] 


control Stellarium through a series of objects that represent the Stel¬ 
larium application components (20). 

3. RELATED WORK 

Video games rose from obscurity in the 1970s, into a video arcade 
industry grossing $8 billion dollars in 1982 [22 p. 88]. The video 
game moved from the arcade into the home with Nintendo and Atari 
game consoles (22, 23 j. Iconography games like Space Invaders , 
Defender , Spaceward HO! and Star Wars were often replaced with 
interactive games that became more realistic m. Wolf suggests 
that there are more than forty different genres of video games ED, 
however, we were only particularly interested in the "Training Sim¬ 
ulation" genre. 

One study showed that video game expertise developed over 
long-term playing had a beneficial effect on the spatial skills in the 
player, supporting the hypothesis that "video expertise could func¬ 
tion as informal education for the development of skill in manipu¬ 
lating two-dimensional representations of three dimensional space" 
01 p- 93]. The aerospace industry has employed training simulators 
for many years, with the advancement in virtual reality environments 
leading to the availability of a new technology known as "serious 
gaming" |24j p. 655]. This technology exploits popular high-quality 
computer games, making it available via Software Development Kits 
(SDKs) to developers of "serious"[sic] applications such as defence, 
surgery, education and aerospace l24ln. 686]. 

One particularly interesting training simulation project was a 
prototype environment for training astronauts in a simulated zero 
gravity environment for the purpose of controlling and handling ob¬ 
jects (25]. Ronkko et al. noted that astronauts discovered using a 
laptop in a zero gravity environment was completely different to us¬ 
ing it on Earth, and that the whole concept of a laptop computer in a 
zero gravity environment was questionable (25] p. 183], 

There have been various implementations of third party integra¬ 
tion with Stellarium. Although it is possible to remotely control a 
telescope using Stellarium as the master controller |26|, some re¬ 
searchers have developed projects whereby Stellarium becomes the 
slave. Tuveri et al. developed two planetarium control systems 
for driving Stellarium on a Laptop computer (27). They extended 
the Stellarium code in order to send it application messages before 
the Remote Control plugin was available in the standard Stellarium 
distribution. One interaction implementation was through a touch 
screen, while the other was through a Kinect gesture controller (27). 

The Remote Control Stellarium plugin was developed by "Flo- 
rian Schaukowitsch in the 2015 campaign of the ESA Summer of 
Code in Space programme" EQl p. 110], and was used for a vi¬ 
sual art installation in the MAMUZ museum for pre-history ED- 
The installation, STONEHENGE. A Hidden Landscape , consisted 
of a single computer driving five projections onto a 15x4m curved 
screen.The presentation was automated with a Raspberry Pi that trig¬ 
gered a script via an HTTP request every twenty-five minutes via a 
cron job. This Remote Control plugin is now a standard part of the 
Stellarium installation. This use of both scripting and HTTP control 
was the mechanism we employed in our game. 

4. DEFINING THE GAMIFIED EXPERIENCE 

One of the intentions of creating the gamified environment was to en¬ 
gage visitors. In the gamified experience, four parties are involved: 
players, designers, spectators, and observers (28). The key to a de- 
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veloping successful gamified experience is to identify who the par¬ 
ties are and how to engage them for the purpose of creating a positive 
and memorable experience (3), each with different levels of involve¬ 
ment or immersion [281. Players were the visitors who physically 
controlled the virtual spacecraft, and in a sense, were the competi¬ 
tors and highly immersed in the experience. Spectators were people 
who do not directly compete in the game, but instead, influenced the 
game indirectly by encouraging the player and were also highly im¬ 
mersed in the experience. Observers were other visitors in the space 
that were passively involved and had no direct impact on the game. 
They were, however, mildly involved and often moved to become 
players or spectators (28). 

Research indicates that the three main factors in developing an 
enjoyable game were challenge, fantasy and curiosity (29). We pro¬ 
vided challenge in that we set a goal that had increasing levels of 
difficulty. As the user was closer to the planet, the spacecraft be¬ 
came more difficult to control. 

We utilised fantasy in that we implement two modes of play: 
terrestrial and spaceship. Terrestrial mode allowed the player to use 
gravity in a familiar way, provided wide fields of view that showed 
large amounts of sky and provided course control. Spaceship mode 
showed less fields of view, displaying significantly less sky and pro¬ 
vided finer control; however, the player was not allowed to use grav¬ 
ity in their control. We enabled the player to zoom in and out by per¬ 
forming a quick twist action of the ball around the string. If the gyro¬ 
scope pitch value exceeded the set threshold, the field of view would 
change, simulating a zoom in or out. When the user changed their 
field of view to less than 30 degrees, the play mode went from ter¬ 
restrial to spaceship. We provided an audible feedback that sounded 
like a zipper when the level of zoom was changed. 

The only controls available at the time on the poi were accelerom¬ 
eter and gyroscope^] while the only feedback was audio generated 
by the poi and the Stellarium display. In the same way that a laptop 
could not be used conventionally in a zero gravity environment (25), 
a player would be unlikely to control the game successfully using 
the poi by spinning it around their body (2). Figure [5] shows the poi 
with three axes of accelerometer and gyroscope on the left and right 
respectively. 



In terrestrial mode, we wanted to simulate a viewer on the ground 
lifting and turning their head to view the sky as one would on Earth, 
which is essentially increasing the altitude and rotating the azimuth. 
The player "lifts their head" by raising the ball of the poi in an arc, 
using the point where the player holds the rope as the centre, and 
measuring Y axis acceleration through the IMU in the poi. Rotating 
the viewer’s head was simulated by detecting the pitch value of the 


11 The button control was added to the poi later. 


gyroscope, as shown on the right side of Figure [5] Gyroscope val¬ 
ues only change while the object is rotating, whereas gravitational 
accelerometer values are maintained when the object is stationary. 

In the spaceship mode, we wanted to simulate the player nav¬ 
igating through space in a zero-gravity environment. The yaw and 
the pitch were used as input, whereby the user had to roll the ball 
in their hands to move the display. This was completely foreign to 
users at first because there was no haptic feedback, nor any sense 
of grounding for the user or the control. In a sense, it was similar 
to balancing on a ball in space because you could not fall off—you 
would just float in an unintentional direction. Furthermore, it was 
not easy to detect which axis was which because the poi was a ball 
shape. Furthermore, rotating one axis would affect the cognition of 
the other axis. Consider a player in Figure [5] rotating the ball for¬ 
ward around the X axis with the poi producing a positive yaw. If 
the player then turned the poi 180 degrees around the string, rotat¬ 
ing the ball forward again would now produce a negative yaw, which 
would mean the screen would start moving in the opposite direction 
to what they experience a moment earlier. The result was that con¬ 
trolling the display required constant mental adjustment, which we 
suggested might simulate to some degree the sense of strangeness an 
astronaut may feel controlling objects in outer space (23 p. 183]. 

In order to run an attractive and engaging display that would trig¬ 
ger the visitors’ curiosity when they entered the room, we ran Stel¬ 
larium scripts that functioned as standalone astronomy shows. We 
invited visitors to manipulate the poi and watch the display move 
while the script was running. When we saw they were interested 
and enjoyed the novelty of interacting with the display through the 
poi, we offered them the opportunity to start from Earth and navi¬ 
gate to one of the planets in our solar system. As they zoomed in 
closer to Saturn, they became quite excited when they saw the rings 
and realised that they could also see Saturn’s moons. For those who 
were particularly enthusiastic, we suggested finding Jupiter next, in¬ 
forming them that they would also be able to see the four Galilean 
moons that night at home with a standard pair of binoculars. We also 
asked them to imagine that rolling the ball to control their movement 
might be as strange as moving about in a zero gravity environment. 
Although a few of the players gave up after a few minutes, the ma¬ 
jority of players continued for more than ten minutes, had a lot of 
fun, and exhibited a sense of achievement in being able to navigate 
into outer space. 


5. DEVELOPMENT 

The system was originally developed as a tool for evaluating the per¬ 
formance, behaviour and suitability of networked control of Stellar¬ 
ium as part of a potential interactive audio visual artwork. We in¬ 
tended to calculate the azimuth and altitude position in space calcu¬ 
lated from the rotation and manipulation of poi. These values would 
be used as input to Stellarium on another device, sent via the net¬ 
work, which would then display the sky based on those values. Ad¬ 
ditionally, we sent commands to change the field of view on Stel¬ 
larium, which effectively acted as a zoom function. The poi also 
played audio as a series of ten uniformly distributed pseudorandom 
sine waves between 500 and 550Hz, giving a sense of cosmic back¬ 
ground microwave noise. 

float freq = hb.rng.nextFloat() * 50 + 500; 

Envelope envelope = new Envelope(1); 
WaveModule soundGenerator = new WaveModule(); 
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soundGenerator.setFequency(freq); 
soundGenerator.setGain(envelope); 
soundGenerator.connectTo(masterGain); 
return envelope; 

A metronome iterates though each of the envelopes, adding segments 
that cause each frequency to momentarily pop out of the background 
as a beep. 

hb.createClock(5000).addClockTickListener(( 
offset, this_clock) -> { 

Envelope e = envelopes.get(envelopIndex++ % 
TOTAL_OSCILLATORS) ; 
final float LOUD_VOL = 20; 
final float LOUD_SLOPE = 20; 
final float LOUD_DURATION = 200; 

e.addSegment(LOUD_VOL, LOUD_SLOPE); 
e.addSegment(LOUD_VOL, LOUD_DURATION); 
e.addSegment(1, LOUD_SLOPE); 

}) ; 

As the user zooms in, the metronome becomes faster, increasing 
the beep rate, generating a sense of sonic tension. 

5.0.1. Starting Stellarium 

The first challenge was starting Stellarium on the Pi from within 
HappyBrackets. HappyBrackets has a simple facility to execute shell 
commands or create processes through both the Java Runtime exec 
and the ProcessBuilder [30]. We attempted a script to run Stellar¬ 
ium from a process command, which ran successfully when executed 
from a terminal; however, we could not get HappyBrackets to run 
the script after each fresh reboot of the device—the program was un¬ 
able to access the display. Interestingly, If we killed the JVM and the 
started HappyBrackets again from a terminal, then Stellarium started 
from within HappyBrackets with no problem. The problem was that 
the HappyBrackets installation script had configured the Raspberry 
Pi to automatically start the Java application when the device first 
boots by executing a script in /etc/local.re as defined in the Raspberry 
Pi documentatiorpq In order to run GUI programs from Java, the 
Java program needs to be started when the desktop starts, which was 
effected by moving the script command to /.config/lxsession/LXDE- 
pi/autostarf^l The HappyBrackets installation scripts were conse¬ 
quently modified to detect whether a desktop version was used, and 
added the HappyBrackets start-up script command accordingly. 

5.0.2. Controlling Stellarium 

Examples of controlling Stellarium through the Remote Control API 
were provided on the plugin developer pag which made use of 
the cURL [ sicp\ command line utilitj^] and executed via an SSH 
terminal connection to the Pi. Although we did not intend to use curl 
in our actual program because Java has its own networking interface, 
curl was extremely useful for examining and diagnosing through the 

lz www.raspberrypi.org/documentation/linux/usage/rc-local.md [accessed 
November 2018] 

L ~ www.raspberrypi.org/forums/viewtopic.php?t=139224 [accessed 

November 2018] 

stellarium.org/doc/head/remoteControlApi.html 

15 curl.haxx.se 

16 cURL should not be confused with the curl programming language. 
ec.haxx.se/curl-name.html [accessed November 2018] 


terminal. Querying the state of Stellarium was performed by issu¬ 
ing a curl GET command. For example, executing the following 
command in the SSH terminal retrieves the current view direction of 
Stellarium as a JSON encoded string. 

curl -G http://localhost:8090/api/main/view 
{"altAz":"[0.954175, 9.54175e-06, 

0.299249]","j2000":" [0.240925, 0.147495, 
-0.959271]","jNow":"[0.241334, 0.148053, 
-0.959082]"} 

Setting the position of Stellarium is executed with the curl POST 
command, with the parameters added as JSON parameters. Execut¬ 
ing the following command would set the display to horizontal by 
setting the altitude to zero. 

curl -d 'alt-0' http://localhost:8090/api 
/main/view 

Having tested the functionality using curl through the terminal, we 
implemented calls using the standard Java URL connections eo. 
We sent control message from the poi via UDP to the slave using 
HappyBrackets and then immediately sent the HTTP message on the 
slave to Stellarium. We found that although the message arrived from 
the poi to the slave in less than a few milliseconds, the time to execute 
the post message on localhost, be actioned by Stellarium, and then 
return typically took between 80 and 120 milliseconds. This pro¬ 
duced accumulative latency when the player continually moved the 
poi. The accelerometer and gyroscope typically update every 10ms, 
so constantly rotating the device for two seconds would generate 
approximately 200 messages. These values would become queued 
inside the slave and sequentially executed, which would result in an 
accumulating latency over a twenty second period. A method was re¬ 
quired that would immediately send the last received position change 
when the last message was complete, but would discard previous 
values that were not yet actioned. We accomplished this through 
an independent thread for executing the post command. This thread 
would be effectively dormant while waiting for an event. When a 
message arrives on a different thread, the event is triggered, at which 
point the thread wakes and sends the message. We effected this 
through the use of Java synchronisation objects. The functionality 
that sends the post messages to Stellarium executes in an indefinite 
loop, laying dormant through the altAzSynchroniser. wait 
() call. 

new Thread(() -> { 

while (!exitThread) { 

synchronized (altAzSynchroniser){ 
try { 

altAzSynchroniser . wait () ; 

} catch (InterruptedException e) 

{ 

e.printStackTrace() ; 

} 

} 

sendAltAz(currentAz, currentAlt); 

} 

}) .start () ; 

The thread will wait indefinitely until it receives a signal from 
variable altAzSynchroniser. When a message to change the 
altitude arrives from the poi, the class variable currentAlt is set 
and the altAzSynchroniser object is notified, which in turn 
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causes the thread shown above to wake and then call sendAltAz 
with the new azimuth and altitude to the localhost. 

public void changeAltitude(double 
control_val) { 

synchronized (altAzSynchroniser){ 
currentAlt = control_val / 2 * Math.PI; 
altAzSynchroniser.notify(); } 

} 

We found that modifying the azimuth and altitude directly often 
produced a jittery display due to the 100ms latency coupled with 
discarding of values that were not actioned while waiting for the 
sendPostMessage call to return. We reduced this problem sig¬ 
nificantly by sending arrow key messages and moved the display left 
and right instead of sending an azimuth. This produced a smooth 
display rotation when rotating the ball. It was not possible to use 
this for the altitude in the terrestrial mode because we were using the 
accelerometer value to determine the height. In the spaceship mode, 
however, this proved very effective as we were able to just send up, 
down, left and right messages based on gyroscope action. 

6. FUTURE WORK 

There were several issues that we discovered through running the 
game. The first problem was that the Raspberry Pi would often crash 
when running the display after a certain period of intense manipula¬ 
tion, however, we were able to run it for several days if we did not de¬ 
mand too many rapid changes from Stellarium. We substituted the Pi 
with a Mac Mini in order to determine where the problems were. We 
found that we were able to reproduce an error in Stellarium on the 
Raspberry Pi when running the script double_stars.ssc that comes 
with Stellarium, however, the Mac ran with no errors. Running the 
kernel journal showed errors indicating an inability to allocate mem¬ 
ory within the GP10 The VC4 OpenGL driver required to run Stel¬ 
larium is still experimental, and it is probably that this is where the 
error lies. Research and development in this area is still required to 
make a stable Raspberry Pi installation of Stellarium. 

We found that when the player started rotating the ball fast, the 
zoom would activate, requiring them to stay within certain rotation 
rates. We modified the game so changing zoom required the player 
to hold the button down when performing a zoom action. 

Messages are sometimes lost over UDP, which became evident 
when a zoom message was sometimes not delivered to the slave. 
We have performed some tests comparing different routers and dif¬ 
ferent Raspberry Pis for packet loss. Additionally, we tested code 
in both Java and C++. We discovered that as packet intervals ex¬ 
ceeded 10ms, the percentage of packet loss increased. Interestingly, 
we found that there was less packet loss using Java than C++ using 
the standard compilers distributed with Raspbian. Furthermore, the 
quality of router had a significant impact. Some routers, although 
supporting multicasting, stopped sending multicast messages to de¬ 
vices after about ten minutes. We intend to perform more tests re¬ 
garding the packet loss, however, the real concern is that broadcast¬ 
ing and multicastling of OSC over UDP is not satisfactory (33]. 

We found that the Just In Time (JIT) compiler took time to con¬ 
vert the downloaded Java byte code into machine code on, produc¬ 
ing a brief stuttering effect when executed for the first time. The 
problem became exacerbated when using the Pi Zero with ten os¬ 
cillators running simultaneously due to the limited power of the Pi 
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Zero. Once the JIT compiler had converted the code, subsequent 
code changes were not affected. Although only an issue when the 
program starts, we need to examine strategies to overcome this. 

7. CONCLUSIONS 

During our research we were able to integrate various open source 
programs to create a system where we could develop and evaluate 
Stellarium as a controllable display element, create inter process 
and device communication using the HappyBrackets Java environ¬ 
ment, and to experiment with the use of the sonic poi as a per¬ 
formance tool. We used this system to create a gamified environ¬ 
ment where visitors were engaged with our technology, providing 
them with a positive and memorable experience. We capitalised on 
this opportunity to observe and evaluate how our system was behav¬ 
ing, which was more memorable to us by virtue of it being part of 
a game that was played repeatedly. We leveraged the quality the 
Stellarium display coupled with a wireless control device to create 
a game that was challenging, fun, engaging and educational. More¬ 
over, the technical goal was to be able to control Stellarium during 
a performance with HappyBrackets, with an example available at 
https://youtu.be/NhXRdd-MNoo 

The research obtained from developing this game can be used 
as a starting point for the development of an interactive educational 
installation. Furthermore, we found a way to expose issues with 
OpenGL driver on the Raspberry Pi, Java JIT, and UDP packet loss 
and performance using both Java and C++. 
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